This PR is nice and we need it, would it make sense to add this?

func EncryptStream(src io.Reader, recipients ... Recipient) (dst io.Reader, error) {
	pr, pw := io.Pipe()
	return pr, EncryptReader(pw, src, recipients...)
}

We wrap it currently as: https://gitlab.com/data-custodian/custodian/-/blob/88e7389ec5b837672f2b76fd82aaed68a4145e72/components/lib-common/pkg/crypto/reader.go

This PR is nice and we need it, would it make sense to add this?

I think this won't work as writes to pipe will block without corresponding reads.

This PR adds a handy function but what you are looking for is the implementation of #644

I'm not sure I follow why this API is needed, or why it requires an internals refactor.

Full pull-based encryption like in #644 I understand, and without an Encrypt(io.Reader) io.Reader API it requires a goroutine, as you point out.

On the other hand, this Encrypt(dst io.Writer, in io.Reader) API only saves a synchronous io.Copy and could be implemented efficiently as

func EncryptReader(dst io.Writer, src io.Reader, recipients ...Recipient) error {
	w, err := age.Encrypt(out, recipients...)
	if err != nil {
		return err
	}
	if _, err := io.Copy(w, in); err != nil {
		return err
	}
	return w.Close()
}

without any other changes, right? Or am I missing something?

only saves a synchronous io.Copy

yes, it avoids unnecessary buffering and copying. I'll close this to avoid confusion.

Oh I see, it avoids one of the copies inside io.Copy. We could do that also by implementing ReaderFrom / WriterTo, right? If you’re hitting a throughput bottleneck, I can add that to the I/O improvements I’m working on.

If you’re hitting a throughput bottleneck

TBH, I did not, I just saw a possible optimisation. Making stream.Writer implement ReaderFrom is the better way.